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(54) rule: Min i lOD FOR STORING XML-FORMAT INFORMATION OBJECTS IN A RELATIONAL DATABASE 

(54) Tiire : I'RCXTEDE DE SIXXTKAGE D'OBJETS INFORMATIONNELS AU FORMAT XML DANS UNE BASE DE DON- 
I W.VS Ri;i.ATIONNELLE 

I _ (57) Abstract: The invention concerns a 

i ^ '-, method for storing information objects or 

I i Riseau^; objects (5) in a relational database (2) Stored 

in a server computer (1), the relational database 
(2) consisting of tables, each formed by a 
table of single data sets having the same data 
structuie in a common table, each single data 
being designated by a single identifier in said 
table, an object (6) consisting of one or several 
single data capable of being stored in a table of 
the database (2), and/or one or several objects 
nested in said object. The nesting can be 
produced on any number of levels to produce 
an object (6), a nested object or a single 
data said to be locally in fixed number if it 
appears exactly once in the object immediately 
containing it and said to be locally in variable 
number otherwise. A single data occurring at 
a particular level of said object (6) is said to be 
globally in fixed number if it is locally fixed 
and all the objects containing it are in fixed 
number, a single data occurring at a particular 
level of said object is said to be invariable 
number if it is locally in variable number or if 
" any one dI" the objects containing it is locally in variable number. The data globally in fixed number of an object to be stored (6) 
J arc stored in a main data set (31 ) stored in a main table (3) of the database (2). The single data globally in variable number of said 
" object to be stored (6) arc stored in one or several auxiliary tables (4, 5, 7) of the database (2). When they exist, the single data 
* globally in variable number ol said objects (6) are stored in a single auxiliary table (7) of the database. The method create one or 
5 several sets of auxiliary data sets (71) to store single data globally in variable number in the single auxiliary table (7). 

\ (57) Abrege : Proccde dc slockage d'objets informaUonnels ou objets (6), dans une base de donnees relationnelle (2) stockee dans 
s UP ordinaicur scrvcur ( 1 ), la base de donnees relationnelle (2) etant constituee de tables, chacune constituee d un tableau d'ensembles 
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la m€me stnicture de donn6es dans une mgme table, chaque donnde simple d'une table est ddsignde par un identifiant unique dans 
ladite table, un objet (6) etanl constitued'une ou plusieurs donnees simples pouvant etre stockfes dans une table de la base de donnees 
(2), et/ou d'un ou plusieurs objets emboftes dans ledit objel. L'emboJlemenl peut etre realise sur un nombre quelconque de niveaux 
pour realiser un objet (6), un objet emboite ou une donnee simple etant dit localement en nombie fixe s'il ou elle apparalt exactement 
une fois dans I'objet le ou la contenant immediatement et efant dit localement en nombre variable dans le cas contraire. Une donnee 
simple apparaissant a un niveau quelconque dudit objet (6) est dile globalement en nombre fixe si elle est localement en nombre fixe 
et si tous les objets la contenant sont localement en nombre fixe, une donnee simple apparaissant a un niveau quelconque dudit objet 
(6)estdite globalement en nombre variable si elle est localement en nombre variable ou si I'un quelconque des objets la contenant est 
localement en nombre variable. Les donnees globalement en nombre fixe d'un objet a stocker (6) sont stockees dans un ensemble de 
donnees principal (31) stocke dans une table principale (3) de la base de donnees (2). Les donnees simples globalement en nombre 
variable dudit objet a stocker (6) sont stocktes dans une ou plusieurs tables annexes (4, 5, 7) de la base de donnees (2). Lorsqu'elles 
existent, les donnees simples globalement en nombre variable desdits objets (6) sont stockees dans une unique table annexe (7) de la 
base de donnees, le procede cree un ou plusieurs ensembles de donnees annexes (71) pour stocker les donnees simples globalement 
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PROCEDE DE STOCKAGE D'OBJETS INFORMATIONNELS AU FORMAT 
XML DANS UNE BASE DE DONTSEES RELATIONNELLE 

La presente invention a pour objet les proc6d6s de stockage d'objets 
informationnels, ou objets, dans un systeme informatique, et plus particulierement, 
5 un precede de stockage, dans une base de donn^es relationnelle traditionnelle, 
d'objets au format extended Markup Language, ou XML, du consortium Internet 
World Wide Web, ou W3C. 

Les systemes de stockage de donnees sont bien connus dans les techniques 
de traitement de I'information, et de plus en plus fr^quemment, ils mettent en CEUvre 
1 0 des systemes de gestion de bases de donnfes relationnelles. 

Ces systemes sont bien adapt6s au stockage de donnees comportant des 
parties en nomhre fixe et des parties en nombre variable, les parties en nombre fixe 
etant stock6es dans une table principale et les parties en nombre variable etant 
chacune stockees dans une table annexe de la base de donn6es. En general, ces 
1 5 systemes permettent en outre de cascader les donnees en nombre variable, c'est-a-dire 
que chaque ensemble ou enregistrement de donnees en nombre variable peut €tre k 
) son tour associe a d'autres donnees en nombre variable. En outre, ces systemes de 

gestion de base de donnees offrent habituellement des possibilites ^interrogation 
sophistiquee, et de bomies performances, m6me sous forte charge. 
20 En I'absence de systemes efficaces de gestion de bases de donnees orient^s 

objets, il est tentant d'utiliser les systemes de gestion de bases de donnees 
relationnelles du commerce pour la gestion et le stockage ou la gestion d'objets. 
Toutefois, ces systemes sont mal adapt6s la gestion d'objets. En effet, dans ces 
systemes traditionnels, les donnees sont stockees dans des tables d'ensembles de 
25 donnees ayant une structure fixe, ces ensembles de donnees etant constitu6s de 
donnees simples. Cela signifie en particulier qu'il n'est pas possible d'imbriquer ou 
d'emboiter des ensembles de donnees a I'interieur d'lm autre, mSme si les ensembles 
de donnees sont en nombre fixe. 

Ce dernier poiat pose probleme pour la gestion d'objets en ce que 
30 TemboTtement d'objets les vms a I'interieur des autres est le fondement meme de la 
gestion de donnees orientee objets. II est theoriquement possible de resoudre ce 
probleme automatiquement en mettant "a plat" la structure de I'objet, c'est-a-dire, en 
considerant que tous les elements de sous-objets inclus dans un objet principal sont 
en fait des elements de I'objet principal. 
35 Cela introduit un nouveau probleme en ce que les noms d'616ments contenus 

dans des sous-objets distincts d'un meme objet peuvent parfaitement Stre identiques 
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et que les noms d'elements dans un meme objet doivent necessairement etre distincts, 
pour d'evidentes raisons de non-ambiguite. Ce nouveau probleme peut a son tour etre 
resolu automatiquement en incluant le nom du sous-objet contenant dans le nouveau 
nom "a plat" d'un element d'un sous-objet. En pratique, cela revient a aj outer les 
5 noms de tous les objets contenants a Moment contenu pour obtenir un nom "a plat" 
noiiambigu. 

Malheureusement, cette technique conduit rapidement a des noms "^i plat" 
ayant une longueur de nom depassant les limites autorisees par les systemes de 
gestion de bases de doim^es, mgme pour des 616ments peu imbriqu6s, du feit que ces 

10 systemes imposent des limites de I'ordre de quelques dizaines de caracteres sur la 
longueur des noms des donnees simples stockees dans une table. Cette nouvelle 
difliculte est habituellement resolue en tronquant le nom "a plat" obtenu a la 
longueur permise par le systeme. Toutefois, ce proc^6 conduit usuellement k des 
noms "a plat" dupliques. 

15 La resolution definitive de ce probleme implique habituellement ime 

intervention manuelle d'un operateur humain, qui defmit lui-meme les noms a utiliser 
dans le systeme de gestion de base de donnees, pour chaque Element d'objet 
imbrique. De fa9on evidente, cette intervention manueUe est sujette i errexir et elle 
est couteuse en temps hum^n. 

20 Par ailleurs, la technique consistant a utiliser une table aimexe pour chaque 

partie en nombre variable d'un objet conduit rapidement k des performances 
deplorables lorsqu'un objet comporte de nombreuses parties en nombre variable, 
conrune c'est souvent le cas en pratique. En effet, chaque acces k im objet stocks dans 
la base de donnees requerra im acc^s la base de donnees pour la table principale 

25 plus autant d'acces a la base de donn6es qu'il y a de tables annexes, c'est-a-dire, de 
parties d'objets en nombre variable dans un objet. Si I'objet comporte, comme il est 
frequent, cinq ou dix parties en nombre variable, le nombre d'acc&s a la base de 
donnees sera multiplie par cinq ou dix par rapport a un objet n'ayant pas de parties 
variables, ce se tiaduit par une degradation des performances dans un meme rapport. 

30 Cette degradation peut devenir critique dans les systemes de stockage de 

donnees tres soUicites, tels que les serveurs Intemet, car il n'est pas toujours possible 
de dupliquer les serveurs pour repartir la charge, en particulier lorsque les donnees 
presentes sur un serveur peuvent etre modifiees. En outi-e, cela augmente dans les 
meines proportions la fragilite du systeme de stockage vis-a-vis d'une panne de 

35 courant ou de tout autre probleme systeme entrainant un arret inopine du systeme 
informatique hebergeant la base de donnees. 
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II existe done vin besoin pour un precede qui permette d'adapter les systemes 
de gestion de base de donn6es relatioimelles existants aux specificity du stockage 
d'objets, en gerant automatiquement les limites imposees sur la longueur des noms 
des donn^es simples stockees dans les tables et limitant le nombre de tables annexes 
5 utilisees pour conserver de bonnes performzinces au systfeme de stockage d'objets 
dans son ensemble. 

La pr6sente invention a done pour objet de proposer un proc6d6 et im 
systeme qui permettent de limiter a une table principale et une table aimexe le 
nombre de tables neeessaire pour stocker les donnees simples en nombre fixe et 
1 0 variable d'une collection d'objets informatiques presents dans un systeme de stockage 
de donn6es. 

La presente invention propose done un proc^6 de stockage d'objets 
informationnels ou objets dans une base de donnees relationnelle stockee dans un 
ordinatevir serveur, ladite base de donnees relationnelle etant constituee de tables, 

15 chaque table etant constituee d'lm tableau d'ensembles de donnees simples, lesdits 
ensembles ayant la mSme structure de donnees dans une mSme table, chaque dorm6e 
simple d'une table etant d6sign6e par un identifiant unique dans ladite table, un objet 
etant constitue d'une ou plusieurs donnees simples pouvant Stre stock6es dans une^ 
table de ladite base de donn6es, et/ou d'un ou plusieurs objets emboit6s dans ledit 

20 objet, ledit emboitement pouvant 6tre realise sur un nombre quelconque de niveaux 
pour realiser un objet, un objet emboitd ou une donnee simple etant dit localement en 
nombre fixe s'il ou elle apparait exactement une fois dans I'objet le ou la contenant 
immediatement et dtant dit localement en nombre variable dans le cas contraire, une 
donnee simple apparaissant k xm niveau quelconque dudit objet etant dite 

25 globalement en nombre fixe si elle est localement en nombre fixe et si tous les objets 
la contenant sont localement en nombre fixe, une donnee simple apparaissant a un 
niveau quelconque dudit objet etant dite globalement en nombre variable si elle est 
localement en nombre variable ou si I'vin quelconque des objets la contenant est 
localement en nombre variable, lesdites donnees globalement en nombre fixe d'lm 

30 objet k stocker etant stockees dans un ensemble de donnees principal stocke dans xme 
table principale de ladite base de donnees, lesdites donnees simples globalement en 
nombre variable dudit objet a stocker etant stockees dans vme ou plusieurs tables 
annexes de ladite base de doimees, qui a pour caract^ristique le fait que, lorsqu'elles 
existent, les donnees simples globalement en nombre variable desdits objets sont 

35 stockees dans une unique table annexe de ladite base de donnees, le proced^ creant 
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un ou plusie;jrs ensembles de donates annexes povir stocker lesdites donnees simples 
globalement en nombre variable dans ladite unique table annexe. 

Dans ce proc^e, chacun desdits im ou plusieurs ensembles annexes 
6ventuellement stocks dans ladite unique table annexe peut comporter en outre un 
5 ensemble d'indicateurs bool6ens, chaque indicateur bool^en 6tant associ^ a une 
donn6e particuli^re desdites donnees simples globalement en nombre variable 
stockees dans ledit ensemble annexe, ledit indicateur booleen indiquant si ladite 
donnee simple globalement en nombre variable associee est definie ou non dans ledit 
ensemble annexe. Dans ce cas, certains desdits indicateurs booMens dudit ensemble 

10 d'indieateurs booleens pourront etre commims h plusieurs donnas simples 
globalement en nombre variable lorsque lesdites doimees simples sent localement en 
nombre fixe dans un mdme objet les contenant immediatement. 

De preference, ledit ensemble principal associe avi dit objet a stocker 
comportera uhe donnde permettant d'identifier de fa^on unique ledit ensemble 

15 principal dans ladite table principale. De plus, ladite donnee unique pourra etre 
imique dans ledit ordinateur serveur, et avantageusement, ladite donnee unique 
stockee dans ledit ensemble principal associ6 au dit objet a stocker sera en outre 
stockee dans chacun des ensembles annexes associ^s au dit objet k stocker, pour 
permettre la mise en relation dudit ensemble principal et du ou desdits ensembles 

20 annexes 6ventuels associ^s au dit objet k stocker. 

De fafon avantageuse, ladite donnee unique pourra 6tre constitute du nom 
logique de I'ordinateur serveur sur ledit rtseau, du numero de table de ladite table 
principale dans ladite base de dormees et du numero d'ensemble de donnees dudit 
ensemble principal dans ladite table principale, ledit nom logique de I'ordinateur 

25 servexir etant unique sur ledit reseau, ladite base de donnees etant unique sur ledit 
ordinateur serveur, ledit numero de table de ladite table principale etant unique dans 
ladite base de donnees et ledit numero d'ensemble de donnees dudit ensemble 
principal 6tant vmique dans ladite table principale. 

Dans le proced^, deux objets h stocker pourront Stre dits de m&me type s'ils 

30 sont constitues de donnees simples et d'objets emboit^s de m6me type, deux objets de 
mSme type ayant en commun un m6me identifiant et les donnees simples et/ou les 
objets emboitts se correspondant 4 un niveau quelconque desdits objets de mSme 
type ayant en commun un meme identifiant, unique dans I'objet les contenant 
immediatement. 

35 Dans ce cas, le procede pouira cr6eir un identiifiant global pour tous les 

objets de meme type et pour toutes les doimees simples se correspondant h im niveau 



wo 02/03245 PCT/FROO/01902 

■ • ■ . ■ 5 

quelconque desdits objets de meme type, ledit identifiant global etant ledit identifiant 
commun pour lesdits objets de meme type, et ledit identij5ant global etant obtenu, 
pour chacxane desdites donnees simples se coirespondant, par la concat6nation des 
identifiants, dans les objets las contenant imm^diatement, de tous les objets 
5 contenant ladite donn^e simple, et de I'identifiant de ladite donnee simple dans I'objet 
la contenant immediatement. 

En outre, le nombie de caracteres de cet identifiant global pourra Stre 
tronqu6 au nombre de caracteres permis par ladite base de donn6es pow I'identifiant 
d'xme donnee stockee dans une table de ladite base de donnees. Egalement, une 
10 ambiguity pouvant apparaJtre du fiiit de ladite troncature pourra 6tre r^solue en 
effectuant les etapes consistant h : 

- remplacer le demier caractere alphabetique de I'identifiant global par le 
chiffre zero, ainsi que les eventuels chif&es le suivant ; 

augnienter d'une unite le nombre constitue par I'ensemble des chififres 
15 apparaissant a la fm dudit identifiant global jusqu'^ ce que I'ambigult^ 

disparaisse ou que les chiffres a la fin dudit identifiant global sbienf 
entierement constitues de chiffres neuf ; 

- r6p6ter les etapes precedentes depuis le d6but lorsque les chiffres 
apparaissant ^ la fin dudit identifiant global sont entierement constitues 

20 de chiffires neuf a Tissue de r^tape pr6c6dente. 

Dans le proced6 de I'invention, les objets stockes dans la base de donnees 
pourront etre re9us ou transmis par I'ordinateur serveur via un t^seau infonnatique de 
type Internet. 

De preference, les donnees simples constituant lesdits objets (6) stockes 
25 dans ladite base de donnees seront de type texte, et avantageusement, lesdites 
donnees simples de type texte seront des donnees ecrites en iangage XML. De plus, 
. lesdites donnees ecrites en Iangage XML pourront etre conformes i une description 
de type XML Schema. 

En outre, im ensemble de donnees au format XML pourra etre obtenu par 
30 une traduction automatique de ladite description, ledit ensemble de donnees et un 
ensemble de donnees complementaire etant a leur tour traduits automatiquement en 
Iangage SQL pour definir et gerer la structure de la base de donnees, et pour controler 
les echanges de donnees avec ladite base de donnees. 

Par ailleurs, dans le procede de I'invention, une partie des donnees simples 
35 des objets re9us par ledit reseau de type Internet pourra etre supprimee a I'aide d'un 
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patron, ou modele, d'objet ecrit en langage XML, pour interdire la modification 
desdites donnees simples via ledit reseau. 

Egalement, une partie des donnees simples des objets transmis via ledit 
reseau pourra etre supprimee a I'aide d'vin patron d'objet ecrit en langage XML pour 
5 limiter la transmission sur ledit reseau k certaines donnees simples desdits objets. De 
plus, la suppression d'lme partie des donndes simples contenues dans les objets 
permettra en outre d'optimiser les requetes a ladite base de donnees. 

L'invention propose en outre xm systeme de stockage d'objets 
infoimationnels ou objets, dans une base de doim6es relationnelle stock^e par un 
10 ordinateur serveur, qui a pour caract^ristique le fait qu'il met en oeuvre le proc6d6 
selon Tune quelconques des revendications prec^dentes. 

Un mode de realisation pref6rentiel de l'invention va maintenant etre decrit, 
. a titre d'exemple seulement, en se r^ferant aux dessins annexes, dans lesquels : 

- la figure l-fest le schema fonctionnel du mode de realisation prefer^ du 
15 procede de stockage d'objets selon la presente invention ; 

- la figure 2 est xm schema montant I'utiUsation d'une table annexe vmique 
pour les ensembles en nombre variable dans le mode de realisation 
pr6fere du proced6 de l'invention sur un cas d'exemple ; 

- la figure 3 est un schema montant I'utiUsation d'un ensemble de tables 
20 annexes pour les ensembles en nombre variables dans la technique 

ant^rievire, sur le mSme cas d'exemple que celui de la figure 2. 
Pour permettre la comparaison, un exemple de stockage d'objet de la 
technique ant^rieure sera Egalement decrit Dans les deux cas, on supposera, de fa9on 
non restrictive, que le systfeme de gestion de base de donnees relationnelle, ou 
25 SGBDR, utilise est mis en oeuvre k I'aide du langage standard Structured Query 
Language, ou SQL. 

Par ailleurs, pour faciliter la comprehension, on decrira les operations de 
stockage concemant un objet 6 d'exemple, tel qu'une entree dans un annuaire 
comportant les informations suivantes : 
30 Entree annuaire : 

Norn, sur 40 caracteres : OTOOBE 
Telephone, sur 15 caracteres : +33(0)1 44 34 85 03 
T^lecopie, sur 15 caracteres : +33(0)1 44 34 85 01 
Adresse : 

35 Rue, sur 40 caracteres : 3bis, rue du Docteur-Foucault 

Ville, sur 40 caracteres : 92000 NANTERRE 
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Adresse : 

Rue, sur 40 caracteres : 34, bd Haussmann 
Ville, sur 40 caracteres : 75009 PARIS 
Contact, sur 40 caracteres : M. Laurent QUEREL 
5 Contact, sur 40 caracteres : M. Jean-Fran5ois QUENUN 

Contact, sur 40 caracteres : M. Gilles ANDRE 

Dans cette entree, les donnfes "Adresse" et "Contact" sent supposees 
pouvoir figuier en nombre variable dans ledit objet 6 "Entree annuaire", pour prendre 
en compte le fait qu'ime entreprise pent comporter plusieurs etablissement et 

10 plusieurs personnes a contacter. Pour la clart6 de I'expose, le nombre des donnees en 
nombre variable a ete limite a deux dans cet exemple, mais ce nombre ne limite en 
rien la portee du precede de la presente invention. 

Les objets informationnels, ou objets, dont la structure de donates n'est pas 
fixe, permettent de prendre en compte ce type de donnees en nombre variable,, ce qui 

1 5 fait toute la puissance de I'approche objet par rapport a une approche traditionnelle oti 
la structure des donnees est fixe, et dans laquelle il est done ndcessaire de prevoir a . 
I'avance un nombre maximal d'occurrences pour chaque donn6e, au risque d'un cot6 
de bloquer de fa9on genante un cas particulier ou un nombre. d'occurrences plus , 
important que celui prdvu serait n^cessaire, et d'un autre cote, de gaspiller 

20 inutilement de la place de stockage dans le cas general pour quelques cas particuliers . 
peu frequents. 

Malheuieusement, les systemes de gestion de base de donnees classiques 
actuels ne permettent pas directement le stockage d'objets, c'est-a-dire de structures 
de donnees permettant I'emboitement de sous-structures de donnees et des 
25 occurrences multiples povir les elements de ces structures, ce qui necessite un 
traitement particulier des donnees de I'objet 6 "Entree annuaire" pour pouvoir le 
stocker dans la base de donnees 2. 

Dans la technique anterieure, ce traitement consiste a separer les dormees en 
nombre fixe "nom", "telephone", "telecopie" et les donnees en nombre variable "rue", 
30 "ville" en stockant les donnees en nombre fixe dans une premiere table principale 3, 
et en stockant les donnees, ou ensembles de donnees, en nombre variable dans autant 
d'autres tables annexes qu'il existe de donnees, ou d'ensembles de donnees, en 
nombre variable dans I'objet 6. 

Dans la technique anterieure, I'objet 6 de I'exemple precedent est alors 
3 5 stocke sous la forme indiqu6 i la figure 3, dans laquelle : 
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- la table 3 est la table-principale stockant les ensembles 3 1 de donnees en 
nombre fixe constitu6s des donndes simples "cle" 11, "nom" 12, 
•Wphone" 13 et "t^lecopie" 14 ; 

- la table 4 est une premiere table amiexe stockant les ensembles 41 
5 constitu6s de la donnde simple "cle" 11 et de la donn& en nombre 

variable "adresse", c'est-^-diie, des donnees simples "rue" 15 et "ville" 
16; 

- la table 5 est une seconde table annexe stockant les ensembles de 
donnees constitues de la donnee "cle" 11 et de la donn^e en nombre 

10 variable "contact" 17. 

Plus precisement, dans I'exemple ci-dessus, la donnee "nom" ayant pour 
valeur "OTOOBE" sera stockee en 12, la donnee "telephone" ayant pour valeur 
"+33(0)1 44 34 85 03" sera stockee en 13, la donnee "telecopie" ayant pour valeur 
"+33(0)1 44 34 85 01" sera stock6e en 14, la donnee "rue" du premier sous-objet 
1 5 "adresse", ayant pour valeur "3bis, rue du Doctevir-Foucault", sera stockee en 15 1, la 
donnee "ville" du premier sous-objet "adresse", ayant pour valeur "92000 
NANTERRE", sera stockee en 16i, la donnee "me" du second sous-objet "adresse", 
ayant pour valeur "34, bd Haussmann", sera stockee en 152, la donn^ "ville" du 
second sous-objet "adresse", ayant pour valeur "75009 PARIS", sera stock6e en I62, 
20 la premiere donnee "contact", ayant pour valeur "M. Laurent QUEREL", sera stockee 
en 17i, la seconde doimee "contact", ayant pour valeur "M. Jean-Fran9ois 
QUENTIN", sera stock6e en 172 et la troisi^e donnee "contact", ayant pour valeur 
"M. Gilles ANDRE", sera stockee en 17^. 

La donnee "cle" 1 1 apparaissant dans les tfois tables 3, 4 et 5 est la cl6 
25 primaire de ces tables, et son utilisation sera decrite plus loin. 

Pour pouvoir utiliser ces donnees, il faut au prealable definir les tables 3, 4 
■ et 5 dans la base de donnees 2, ainsi que les di verses donnees stockees dans ces 
tables 3, 4 et 5. 

Dans la technique anterieure, pour creer la table 3, un operateur devait 
3 0 typiquement indiquer manuellement au SGBDR une instruction SQL du type : 
CREATE TABLE "EntreeAnnuaire main" ( 
cle INTEGER, 
nom VARCHAR(40), 
telephone VARCHAR(15), 
35 telecopie VARCHAR(15), 

PRIMARY KEY (cle)) 
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Dans cette instruction, la rabrique "EntreeAnnuaire_main" indique le nom, 
librement choisi par I'operateur sous r6serve d'unicit6, de la table principale 3, et une 
rubrique "VARCHAR(n)" indique une chaine de caracteres de longueur variable et 
de longueur maximale n. La donnee "cle" 11 est la cle primaiie evoqu^e ci-dessus et 
5 qui sera decrite plus loin, et la rubrique "PRIMARY KEY(cle)" indique precisement 
au systeme que cette donnee "cle" 1 1 est la cl6 primaire. 

De meme, dans la technique ant^rieure, pour cr^er les tables 4 et 5, un 
operateur devait typiquement indiquer manuellement au SGBDR des instructions 
SQL du type: 
10 CREATE TABLE "EntreeAnnuaire_l"( 

cle INTEGER, 
rue VARCHAR(40), 
villeVARCHAR(15), 
PRIMARY KEY (cle)) 

15 CI : 

CRUA I E TABLE "EntreeAnnuaire_2" ( 
cIcINTEGER, 
contact VARCHAR(40), 
PRIMARY KEY (cle)) 

20 dans lesquelles les rubriques "EntreeAnnuaire_l" et "EntreeAnnuaire_2" sont les ^ 
noms respectifs, librement choisis, des tables annexes 4 et 5. 

En outre, I'operateur devait d^finir 6galement manuellement les donnees 
indexees, c'est-a-diie les donnees dont le contenu pourra permettre de retrouver une 
entree de I'annuaire, au moyen d'instructions SQL du type : 

25 CREATE INDEX "IndexNom" ON "EntreeAnnuaire_main" (nom) 

qui indique au SGBDR de faire en sorte qu'une entr6e d'annuaire puisse €tre 
retrouvee par le contenu de la rubrique "nom" de la table principale 3 
"Entree Annuaire_main" . 

De plus, dans le cas d'objets 6 comportant de nombreux niveaux 

30 d'emboitement et de nombreuses donnees en nombre variable comme c'est souvent le 
cas en pratique, le nombre de tables annexes etait eleve, et la numerotation ou la 
denomination des tables annexes etait beaucoup plus complexe que celle presentee 
dans I'exemple precedent. A nouveau, cette nvimerotation ou cette denomination 
necessitait une intervention manueUe d'un operateur, avec les risques d'erreur 

3 5 inherents a toute operation manuelle. 
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En se referant aux figiu-es 1 et 2, on va maintenant decrire le precede de 
stockage selon le mode de realisation prefere de I'invention, qui est mis en ceuvre par 
divers modules de programmes globalement d6nomm6s Collective Operating System 
ou COS dans ce document. 
5 En revenant k I'exemple pr^c^ent, le precede de I'invention gere I'ensemble 

31 de doimees simples en noinbre fixe "cle" 11, "nom" 12, "telephone" 13, et 
"telecopie" 14 dans la table principale 3 de la meme maniere que dans la technique 
ant^rieure, c'est-a-dire en utilisant directement les primitives ad^uates du SGBDR 
utilise. 

10 Par centre, la gestion des donnfes simple en nombre variable est effectuee a 

I'aide d'une unique table 7, au lieu des tables 4 et 5. Pour cela, le prpc&i6 de 
I'invention stocke la premiere occurrence d'une donn^ simple en nombie variable 
dans un premier ensemble de donnees 71] de la table 7, la seconde occurrence d'une 
donnee simple en nombre variable dans un second ensemble de donnees 7l2 de la 

15 table 7, la troisieme occurrence eventuelle d'une donn6e simple en nombre variable 
dans un troisieme ensemble de donnees 7I3, etc.. On voit alors que la structure de 
donnees de la table 7, c'est-a-dire la structure des ensembles de donnees 71, doit 
n^essairement comporter au moins I'vmion des donnees simples en nombie variable 
dans un objet 6. 

20 Comma dans la technique ant&ieure, la doimee "cle" 1 1 apparaissant dans 

les deux tables 3 et 7 est la cM primahe de ces tables, et son utilisation sera d^crite 
plus loin. 

En revenant k I'exemple pr6c6dent, le precede stocke done la donnee 
premiere occurrence de la doim6e simple "riie" de I'objet 6 dans I'emplacement 15i de 

25 I'ensemble 71] de la table 7, il stocke la premiere occurrence de la donn6e "ville" 
dans I'emplacement I61 de I'ensemble 71i de la table 7, il stocke la seconde 
occurrence de la donnee "rue" dans I'emplacement 152 de I'ensemble 7I2, il stocke la 
seconde occurrence de la donnee "ville" I62 dans I'emplacement 1 62 de I'ensemble 
7I2, il stocke la premiere occurrence de la donnee "contact" 17i dans I'emplacement 

30 17i de I'ensemble 71i, il stocke la seconde occurrence de la donnee "contact" 172 
dans I'emplacement 172 de I'ensemble 7I2, et il stocke la troisieme occurrence de la 
donnee "contact" I73 dans I'emplacement I73 de I'ensemble 71 3. 

Toutefois, on voit dans ce qui precede que les emplacements correspondants 
aux donntes simples "rue" et "ville" aux emplacements I53 et I63 dans I'ensemble de 

35 donnees simples 7I3 ne sont pas remplis, ce qui est dxi au fait qu'il n'y a que deux 
ensembles de donnees en nombre variable "rue" et "ville", et qu'il y a trois donnees 
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en nombre variable "contact". Cela pose un probleme en ce sens que si les ensembles 
de donnees simples 71 1, 7I2, 7I3 etaient stock6s en I'^tat dans la base de donntes, 
rinformation concemant quels emplacements sent rempUs et quels emplacements 
sent vides serait longue et difficile a determiner. II serait en effet necessaire de tester 
5 la nullity des colonnes de I'ensemble de ces donnees simples nombre variable pour 
determiner I'absence ou la presence de ces donnees en nombre variable. 

Pour resoudre ce probleme, le proced^ selon I'invention reservera en outre, 
dans chaque ensemble 71, des emplacements de donn&s pour stocker cette 
infonnation de presence ou d'absence pour chaque donnee en nombre variable dans 
10 cet ensemble 71. 

En pratique, dans le cas de donnees simples en nombre fixe, telles que "rue" 
et "ville" associees dans un meme sous-objet contenant tel que "adresse", les donnees 
simples en nombre fixe associees seront toujours presentes ou absentes 
simultanement, ce qui signifie que le precede pourra optimiser le nombre 
15 d'indicateurs en ne stockant qu'vin seul indicateur par ensemble de donnees en 
nombre fixe associees. 

Dans ces conditions, lors de la creation de la table 7, le proc6d6 ajoute dans 
la structure de donnees de la table 7, c'est-a-dire dans chaque ensemble 71, une 
donnee booleenne pour chaque ensemble de donnees en nombre variable dans I'objet 
20 6. Dans I'exemple decrit, I'ensemble de donnees simples 72 constitu6 des donn6es 
simples bool6ennes 20 et 21 est ainsi ajoute h chaque ensemble 71, la donn6e 
booltenne 20 indiquant la presence, dans I'ensemble 71 considere, de I'ensemble 
constitu6 des donnees simples "rue" 15 et "ville" 16, et la donnee booleenne 21 
indiquant la presence, dans I'ensemble 71 consid6re de la donn6e "contact" 17. 
25 Ainsi, les informations de presence ou d'absence des donnees ou des 

ensembles de donnees en nombre variable seront conservees lors de I'ecriture d'un 
objet 6, et le precede pourra utiliser ces informations lors des relectures ulterieures, 
pour reconstituer correctement I'objet 6 tel qu'il etait au moment de son 
emegistrement. 

30 On notera qu'avec le precede de I'invention, le nombre d'ensembles de 

donnee presents dans I'unique table annexe est egal au maximum des nombres des 
donnees en nombre variable dans I'objet 6, alors que ce nombre d'ensembles de 
donnees dans les tables annexes est egal a la somme des nombres de donnees en 
nombre variable de I'objet 6 dans la technique ant6rieure, c'est-a-dire un nombre 

35 toujours plus eleve. 
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Par ailleurs, dans le mode de realisation preferentiel, le precede est utilise 
pour stocker des objets 6 Merits en langage XML qui sont confonnes k une 
description 92 de type XML Schema, ce qui signifie en particulier que cette 
description est elle-mdme ecrite dans le langage XML. 

Cette description 92, d^nommee COSSchema dans le mode de realisation 
preferentiel, d^crit la structure de donnees des objets 6. L'int&et de cette desaiption 
XML Schema 92 est de constituer une definition de reference unique pour la 
structure des objets 6, modele qui sera utilise chaque fois qu'il sera necessaiie de 
verifier la structure ou la validite des objets 6. 

Dans le mode de realisation preferentiel, un certain nombre de definitions 
J objcts iitiJisees dans le schema COSSchema 92 sont derivees a partir de definitions 
sttK-kccs dans un autre schema XML Schema 91, denomme COSCoreSchema. 

L'interet de cette approche est de permettre au COS d'uniformiser les 
definitions de certains objets en lem: donnant une base commime, et de pouvoir 
cxcntucllement effectuer un certain nombre de travaux, en particulier de 
maintenance, do fafon homogene sur ces objets. Par exemple, s'il s'avere necessaire 
d'intnxJuire une nouvelle donnee simple ou de modifier ime donnee simple existante 
dans un type de base defini dans le COSCoreSchema, il ne sera pas necessaire de. 
reproduire la nouvelle donnee simple ou la modification dans tous les objets bases 
sur ce type, et la modification sera implicitement reproduite via la seule reference au 
type de base. Ainsi, les risques d'erreur au niveau de la structure des objets COS 
seront reduits d'autant, et la maintenance de ces objets s'en trouvera facili^. 

En revenant h I'exemple d'entree d'annuaire vue precedemment, dans le 
mode de realisation prefere de rinvention, celle-ci sera constituee d'vm objet 6, se 
presentant en langage XML sous la forme suivante : 
<entree_annuaire> 

<nom>OTOOBE<v'nom> 

<telephone>+33(0)l 44 34 85 03</telephone> 

<telecopie>+33(0)l 44 34 85 01</telecopie> 

<adresse> 

<rue>3bis, me du Docteur-Foucault</rue> 
<ville>92000 NA]SrrERRE</ville> 
</adresse> 

<adresse> i 
<rue>34, bd Haussmann</rue> 
<ville>75009 PARIS</ville> 
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</adresse> 

<contact>M. Laurent QUEREL</contact> 
<contact>M. Jean-Fran9ois QUENTIN</contact> 
<contact>M. Gilles ANDRE</coiitact> 
5 </entree_annuaire> 

Cet objet sera typiquement conforme a nn fragment du COSSchema, qui est 
de t>T>e XML Schema, se presentant sous la forme suivante : 
<type name="entree_annuaire"> 

<element iiame="nom" minOccurs="l"> 
10 <datatype source="string"> 

<length value="40"/> 
</datatype> 
</elemeiit> 

<element iiame="telephone" minOccurs="l"> 
15 <datatype source="string"> 

<length value="15"/> 
.</datatype> 
</element> 

<element name="telecopie" minOccurs="r'> 
20 <datatype sovirce="string"> 

<length value="15"/> 
</datatype> 
</element> 

<typename="adresse" minOccurs="l" maxOccurs="*"> 
25 <element name="rue" minOccurs=" 1 "> 

<datatype source="string"> 
<length value="40"/> 

</datatype> 
</element> 

30 <element name="ville" minOccurs="l"> 

<datatype source="string"> 
<length vEdue="40"^ 
</datatype> 
</element> 
35 </type> 

<element name="contact" minOccurs="0" maxOccvirs="*"> 
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<(iatatype source="string"> 
<length value="40"/> 
</datatype> 
</element> 
5 <type> 

Dans cette definition XML Schema, le paramStre 'minOccurs' d'une donnee 
simple ou d'un sous-objet emboite indique le nombre minimum de fois oil la domiee 
concemee apparait dans I'objet immediatement contenant, et le paramdtre 
'maxOccurs' d'vme doimee simple ou d'un sous-objet emboite indique le nombre 
10 maximum de fois oil la donnee concemee apparait dans I'objet immediatement 
contenant. Par d^faut, c'est-a-dire lorsque 'maxOccuis' n'appaxait pas, il est suppps6 
etreegalal. 

La signification de 'maxOccurs="*"' est que la donnee ou le sous-objet 
conceme peut apparaitre im nombre quelconque de fois dans I'objet immediatement 
15 contenant. 

Dans le mode de realisation pr6fere de I'invention, le proc6d^ utilise cette 
description au format XML, en association avec le proc^d^ de stockage d'objets dans 
seulement deux tables qui a ete d6crit plus haut, pour g6n6rer automatiquement des 
instructions SQL pour cr^r et gerer les donn6es de la base de donntes 2 repr6sentant 

20 les pbjets stock6s. 

Pour cela, le procdd^ de I'invention part du COSSchema et il applique im 
certain nombre de regies pour obtenir un format XML Schema etendu, d6nomm6 
XDB Schema, comparable a celui de I'exemple decrit ci-dessus. En effet, dans le 
COSSchema, la description des donnees est faite, de fa9on structuree, en se r6f6rant k 

25 d'autres types predefinis, tels que les types definis dans le COSCoreSchema ou a des 
. types intermediaires definis dans le COSSchema lui-meme. Pour rendre utilisables 
dans le langage SQL utilise les informations presentes dans le COS Schema, le 
proc6d6 de I'invention, applique done k ce schema COS Schema vm certain nombre 
de regies de traduction lui permettant de passer d'une representation comportant des 

30 types non simples a une representation ne comportant plus que des types simples. Le 
resultat de cette traduction constitue le schema XDB Schema. 

Toutefois, le schema XDB Schema obtenu pr6cedemment n'est pas svifGsant 
a lui seul pour definir complfetement la structure de I'objet 6 dans la base de donnees 
2 : en effet, il manque les informations permettant de definir les donnees de I'objet 6 

35 qui seront index6es. Pour resoudre ce probleme, le precede de I'invention utilise un 
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schema XML 96 complementaire, denomme XDB Mapping, decrivant les donnees a 
indexer dans les tables stockant les donnees de I'objet 6. 

Ce schema XDB Mapping 96 reprend la structure du schema COSSchema 
en la limitant aux donnees devant fEiire I'objet d'une indexation, Ainsi, dans I'exemple 
5 precedent ou la donnee "nom" devait Stre indexee, le fragment correspondant dans le 
XDB Mapping sera du type suivant : 
<type name="entree_annuaire"> 

<element naine="nom" sql:indexname="IndexNom" sql:indexType="„."/> 
</type> 

10 at la. rubrique "sqhindexname" indique le nom de I'index a cr6er, ici "IndexNom", et 
oil la rubrique "sqlrindexType" sert k indiquer, sous une syntaxe adequate, des 
parametres pour I'index a creer, tels que "ordre de tri croissant", "pas de distinction 
minuscules/majuscules", etc.. Ainsi, avec ce schema XDB Schema, le proc^6 de 
I'invention possede toutes les informations utiles pour cr^er automatiquement dans la 

1 5 base de donnees 2 toutes les donnees necessaires pour I'objet 6 a creer. 

Ensuite, le precede ti-aduit ces schemas XDB Schema et XDB Mapping en 
instructions SQL k destination du SGBD gerant la base de donnees 2. 

Toutefois, avant de pouvoir mener a bien cette operation, un autre probleme, 
lid aux possibilites offertes par les objets, doit etre rdsolu. En effet, I'approche 

20 orientee objet permet k des donnees simples, ou a des sous-objets, contenus dans des 
sous-objets distincts d'avoir le meme identifiant, pourvu que cet identifiant soit 
unique dans le sous-objet, ou I'objet 6, les contenant imm6diatement. Cette 
possibility de noms dupliques dans des sous-objets differents interdit d'utiliser 
directement ces identifiants comme identifiants globaux de donnees dans la base de 

25 donnees 2, car devix donnees distinctes d'une m§me table pourraient alors recevoir le 
m&me identifiant, ce qui est interdit par tons les SGBDR existants. 

Pour resoudre ce probleme, le procede cree pour chaque donnee simple un 
identifiant global obtenu en prefixant I'identifiant de la donnee simple, tel qu'il 
apparait dans la rubrique 'name="..."' de la definition de la donnee simple dans le 

30 schema XDB Schema, par la concatenation des identifiants, tels qu'il apparaissent 
dans les rubriques 'name="..."' des defmitions correspondantes du schema XDB 
Schema, de tous les sous-objets contenant, a une niveau ou un autre, la donnee 
simple considdree. Ce procede leve rambiguite qui pourrait apparaStre, car du fait que 
les identifiants des donnees simples ou des sous-objets dans leurs objets 
35 immediatement contenant sont distincts, deux identifiants globaux obtenus de cette 
fafon sont necessairement distincts globalement. 
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Ainsi, dans I'exemple ci-dessus, ridentifiant global de la donnee "nom" sera 
"nom" lui-meme, puisque la dojonee simple "nom" n'est pas contenue dans un sous- 
objet ; par centre, I'identifiant global de la donn6e "rue" contenue dans le sous-objet 
"adresse" sera "adresse_rue". 
5 Dans ce qui precede, on a indique que les identifiants des donn^es creees 

danis les tables 3 et 7 de la base de donnees 2 etait la concatenation des identifiants de 
la donnee et de tous les sous-objets la contenant dans I'objet 6. Toutefois, cela pose 
probldme en ce que la longueur de ces identifiants est habituellement limit^e par les 
SGBDR classiques h une valeur assez basse, de I'ordre de quelques dizaines de 
10 caracteres, et que, pour des objets comportant un niveau d'emboitement meme 
modere, cette limite est tres vite atteinte. 

Pour r^soudre ce probl^me, le proc^de de I'invention tronque les identifiants 
prec^denunent obtenus k la longueur permise par le SGBDR pour les identifiants de 
donnees d'une table. A Tissue de cette troncature, si I'identifiant global obtenu est 
15 ddja present dans la table ou il devait etre cree, le precede de I'invention realise les 
6tapes suivantes : 

1°/ le dernier caractere alphabetique de I'identifiant global prec6denunent 
obtenu est remplac6 par le chiffie "0", ainsi que tous les chif&es le suivant 
6ventuellement ; 

20 2°/ si I'identifiant global ainsi obtenu est encore pr6sent dans la table, le 

nombre constitue par I'ensemble des chif&es apparaissant a la fin de I'identifiant 
global est augmente d'une unite et I'dtape 2 est rep6t6e tant qu'un nombre entidsrement 
constitue de chiffires "9" n'a pas 6t6 atteint ; 

3°/ si un nombre entiSrement constitu6 de chii&es "9" est atteint k I'dtape 2, 
25 alorsleproc6d6retoume&r6tape 1. 

Les etapes 17 a 37 precedentes sont repetfes jusqu'^l ce qu'un identifiant 
global, nouveau dans la table consideree, soit trouv6. 

Ainsi, le precede ci-dessus decrit permet de lever les ambiguites, dans les 
identifiants globaux attribues aux donnees simples stockees dans la base de donnees 
30 2, qui peuvent apparaitre du fait de la possibilite de duplication d'un identifiant de 
donnee ou de sous-objet dans des sous-objets distincts. 

En utilisant ce precede de generation d'identifiants globaux pour les donnees 
simples d'un objet 6, le proc6d6 relit alors en parallele le schema XDB Schema et 
XDB Mapping, et pour chaque nouveau type d'objet a creer 6 trouve dans le schema 
35 XDB Schema, il applique le proced6 suivant : 
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- le precede cree aiors dans la base de donn^es une table principale 3 
portant le nom de I'objet 6, suivi du siiffixe "_main", comportant une 
doiui6e "cle" 11 servant a identifier de fe^on unique dans la base de 
donn6es un objet 6 ; ainsi, Iprsqu'il rencontre dans le schema XDB 

5 Schema la definition : 

<type name="entree_annuaire"> 

</type> 

le proced6 cr6e la table principale 3 "EntreeAnnuairemain" 
10 correspondante par I'instruction SQL : 

CREATE TABLE "Entree Aimuaire main" (cle INTEGER, 
PRIMARY KEY (cle)) 

- ensuite, le precede explore les definitions "<element ...>...</element>" du 
schema XDB Schema, XDB Schema et pour chaque donnee simple 

15 rencontree, telles que "nom" ou "contact", il determine si cette dorm^e est 

en nombre fixe ou variable ; une donnee simple sera dite en nombre fixe 
si sa rubrique "maxOccurs" est absente de la definition et si cette donnee 
simple n'est pas contenue k un niveau quelconque dans un sous-objet en 
nombre variable, c'est-^-dire un sous-objet dont la rubrique "maxOccurs" 

20 serait pr&ente et difKrente de la rubrique "minOccurs" dudit som-objet ; 

vns donnee sera dite en nombre variable dans le cas conteaire, c'est-i-dire 
si elle n'est pas en nombre simple au regard de la definition precedente ; 

- lorsque le proced6 rencontre une donnee en nombre fixe telle que la 
donn6e "nom" dans I'exemple ci-desstis, il ajoute cette donnee en nombre 

25 fixe dans la table principale 3 a I'aide d'une instruction SQL telle que : 

ALTER TABLE "EntreeAnnuaire_main" ADD nom VARCHAR(40) 
dans laquelle I'identifiant global "nom" est obtenu par le procede decrit 
plus haut, et dans laquelle la longueur "40" apparaissant dans la rubrique 
"VARCHAR" est reprise de la '<length value="...">' de la definition 

30 correspondante ; en outre, si le procede trouve dans le schema XDB 

Mapping une definition d'index portant sur la donnee qu'il vient de creer 
dans la table principale, le procede cree vm index pour cette donnee a 
I'aide d'une instruction SQL adequate telle que : 
CREATE INDEX "IndexNom" ON "EntreeAnnuaire_main" (nom) 
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dans laquelle le nom de I'index "IndexNom" est celui retiouv^ dans la 
rubrique "sql:indexname" de la definition correspondante du schema 
XDB Mapping; 

lorsque le proced6 rencontre une dounee en nombre variable telle que la 
doim6e "contact" dans I'exemple ci-dessus, 11 effectue les operations 



■ s'il n'existe pas dej^ xine table annexe 7 associee a cette table 
principale 3, il cree cette table annexe a I'aide d'une instruction SQL 
telle que : 

10 CREATE TABLE "EntreeAnnuaire_annex" (cle INTEGER, 

PRIMARY KEY (cle)) 

■ dans laquelle la donnee "cle" est la donnee servant k identifier de 
fa9on unique un objet 6 dans la base de donnees 2 ; 

■ ensuite, le precede cree la donnee correspondante dans la seconde 
15 table, en lui associant, de la fa9on ddcrite pr6c6deniment, une 

dojon^e booleenne "presence", permettant de savoir si la donnee 
correspondante est pr6sente ou non dans I'ensemble de donnees 71 
consid6r6; par exemple, pour la doim^ en nombre variable 
"contact" 17, cette cr^tion sera r^is6e a I'aide d'une instruction 
20 SQL telle que: 

ALTER TABLE "EntreeAnnuaiie_annex" ADD contact 
VARCHAR(40), ADD presence_contact BOOLEAN 

■ dans laquelle I'identifiant global est obtenu par le procede decrit 
plus haut, et dans laquelle longueur "40" apparaissant dans la 

25 rubrique "VARCHAR" est reprise de la rubrique '<length 

value="...">' de la definition correspondante dans le schdma XDB 
Schema ; 

■ dans le cas d'une donn6e incluse dans un sous-objet comme la 
donn6e "rue", I'identifiant global sera obtenu comme indiqu6 

30 pr6c6demment, et I'instruction SQL correspondante sera, par 

exemple : 

ALTER TABLE "EntreeAimuaire_annex" ADD adresse_rue 

VARCHAR(40), ADD presence_adresse_rue BOOLEAN. 
Le proc^d6 r6pete les operations pr6c6dentes jusqu'^ ce que toutes les 
35 definitions pr6sentes dans le schema XDB Schema 61 aient €t6 traitees, A Tissue de 
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ce traitement, le precede aura done cr6e automatiquement la structure d'objets 6 dam 
la base de donnees 2, telle qu'elle etait decrite dans le schema COS Schema. 

Dans le mode de realisation de la presente invention, les aspects ci-dessus 
du precede de I'invention sont impl6mentes dans un programme 90 denomm^ XBD 
5 Engine, et, contrairement a la technique anterieure, le precede de I'invention i)ermet 
de realiser la creation de nouveau type d'objet 6 dans la base de donn6es 2 sans 
intervention manuelle d'un op6rateur, ce qui se traduit par un gain de temps trts 
appreciable et une diminution consid^able du risque d'erreur, tant pour la creation 
que pour la modification, dans la base de donnees, de la structure d'un objet 6. 

10 Dans ce qui precede, on a decrit le proced6 de I'invention comme 

transformant le schema COSSchema, comportant des types predefinis, en im schema 
XML, le schema XDB Schema, ne comportant plus que des types de doimees simples 
tels qu'utilises par le SGBDR. Cela a ete fait dans I'optique de I'utiHsation d'un 
langage SQL de base, qui ne connait pas de types autres que ces types simples. 

15 Toutefois, dans le cas de I'utilisation d'lm langage SQL evolue, tel que le 

langage SQL 3, le precede de I'invention tirera naturellement parti des possibilites de 
typage offertes par ce langage en ne traduisant en types plus simples que les types ne 
pouvant pas Stre "compris" directement par le langage SQL utilise. Les types utilises 
par le COS Schema et pouvant Stre traduits dnectement en types SQL, le seront a 

20 I'aide d'tme instruction SQL adequate, telle que : 
CREATE TYPE... 

Dans ce qui precede, on a d6crit sur un exemple les Stapes de creation d'un 
nouveau type d'objet 6 a stocker dans la base de donnees 2, tant dans la technique 
ant6rieure que dans le proc6de de I'invention. Les informations contenues dans 
25 COSSchema et XDBSchema seront bien 6videmment reutiUsees pour modifier la 
structure d'un objet 6 d^ja existant dans la base de donnees 2, apres que les 
modifications voulues y aient ete apportees. Cette modification de la structure d'un 
type d'objet 6 deja existant est en tout point similaire a la creation precedemment 
decrite. Ainsi, par exemple, pour modifier une table 3'; existante et y ajouter un 
30 nouveau champ, rinstruction SQL utilis6e, tant dans la technique anterieure que dans 
le procede de I'invention : 

CREATE TABLE ... 
sera remplacee, par exemple, par I'instruction SQL : 

ALTER TABLE "EntreeAnnuaire_main" ADD telex VARCHAR(15), 
35 DROP telecopie 
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qui indique qu'une donnee "telex" sur quinze caracteres doit etre ajoutee et que la 
doimi^e "telecopie" doit etre supprim^e. 

De meme, la suppression de I'index sur la donnte "nom" dans la table 3 se 
ferait, tant dans la technique ant^rieure que dans le proc6d6 de I'invention, par 
5 rinstmction SQL : 

DROP INDEX EntreeAnnuaire.IndexNom 

Dans le cas du precede de I'invention, k nouveau ces modifications sont 
effectuees de fa9on automatique par le programme XDB Engine. 

Compte-tenu de ces similitudes, la modification de la structure d'un objet 6 
1 0 stocke dans la base de donnees 2 par le precede de I'invention ne sera pas decrite plus 
en detail. 

Dans ce qui suit, on va maintenant decrire le fonctionnement du proc6d6 
selon la presente invention en comparaison avec la technique anterieure pour le 
stockage et la gestion des donnees en nombre variable d'un objet 6. 

15 En se referant aux figures 2 et 3, un systeme de stockage des donnees 

siinples d'un objet 6, dans la technique anterieure comme dans le proc^^ de 
I'invention, est constitu^ d'un ordinateur 1 h6bergeant ime base de donnees 
relationnelle 2. Les ensembles de donnees simples d'une table principale telle que la 
table principale 3, ou ceux d'une table annexe telles que les tables 4, 5 ou 7, soht 

20 geres a I'aide des fonctions offertes par le systdme de gestion de base de donnees 
relationnelle ou SGBDR, utilise poxir la gestion de la base de donnees 2. 

Ces fonctions comprennent au minimum une fonction d'ecrituie ou de 
creation d'un ensemble de donnees simples dans une table, une fonction de lecture 
d'lm ensemble de donnees simples depuis une table, une fonction de suppression d'un 

25 ensemble d'une table, et une fonction de recherche d'un ensemble par son contenu, la 
fonction de modification d'un ensemble pouvant etre assimilee, pour la simplicite de 
• I'expose, a une lecture de I'ensemble suivie d'une ecriture de I'ensemble modifie. Par 
cons6quent, cette fonction ne sera pas decrite davantage. 

Dans ce qui smt, on va comparer les performances, en termes de nombres 

30 d'ensembles de donnees echang^s avec la base de donnas 2, respectivement pour la 
technique anterieure et le proc6d^ de I'invention. 

En se r^fdrant Sl la figure 3, dans la technique anterieure, la base de donnees 
2 comporte une table principale 3 stockant les ensembles 31 de donnees simples en 
nombre fixe "nom" 12, "telephone" 13 et "telecopie" 14, et cette table principale est 

35 en relation avec deux tables annexes 4 et 5 contenant les ensembles 41 et 51 de 
donnees simples en nombre variable, respectivement les ensembles 41 constitu6s des 
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donnees simples "rue" 15 et "ville" 16 pour la table annexe 4, et les ensembles 51 
constitues de la donnee "contact" 17 pour la table annexe 5. 

De fa9on classique, une donnee d'identification unique "cle" 11, presente 
dans les ensembles 31, 41 et 51 respectivement stockes dans les tables 3, 4 et 5, est 
5 utilisee pour mettre en relation, c'est-a-dire faire se r6ferencer, la table principale 3 et 
les tables annexes 4 et 5. 

1 °l Ecriture d'un objet 6 dans la base de donnees 2 

L'ecriture, ou creation, d'un objet identifi6 par une valeur unique teUe que 
1234 et comportant les donnees simples en nombre fixe "nom" 12, "telephone" 13, 
1 0 -iclccopie" 14, associ^es aux donnees simples "rue" 15, "ville" 16 et "contact" 17 en 
nt»n>ba- \ ariable, comportera classiquement les etapes suivantes : 

- ecriture de rensemble principal 31 constitue des donnees simples "cle" 
11. "nom" 12, "telephone" 13 et "telecopie" 14 dans la table 3 a I'aide de 
la fonction correspondante du SGBDR, en initialisant la donnee "cle" 1 1 
15 a la N'aleur 1234 ; cela pourra etre realise, par exemple, a I'aide d'une 

instruction SQL telle que : 

INSERT INTO "EntreeAnnuaire_main" (cle, nom, telephone, telecopie) 
VALUES (1234, "OTOOBE",, "+33(0)1 44 34 85 03", "+33<0)1 44 34 85 
01") 

20 - ecriture de deux ensembles 41 constitues des doim6es simples en nombre 

variable 15 et 16 a I'aide de la fonction correspondante du SGBDR, en 
initialisant dans chactm la donn6e "cle" 11 i la valeur 1234, c'est-^-dhe, 
ecriture des deux ensembles 41 1 et 4I2 constituds respectivement des 
donnees simples "cle" 11, "rue" 15i, "ville" I61 d'une part, et des donnees 

25 simples "cle" 11, "rue" 152, "ville" I62 d'autre part ; cela pourra atre 

realist, par exemple, par les instructions SQL : 

INSERT INTO "EntreeAnnuaire_l " (cle, rue, ville) VALUES (1234, 
"3bis, rue du Docteur-Foucault", "92000 NANTERRE") 
et : 

30 INSERT INTO "EntreeAnnuaire_l " (cle, rue, ville) VALUES (1234, "34, 

bd Haussmann", "75009 PARIS") 
- ecriture de trois ensembles 51 a I'aide de la fonction correspondante du 

SGBDR, en initialisant la donnee "cle" 11 a la valeur 1234, c'est-^-dire, 

ecriture des trois ensembles 51,, 5l2 et 5I3 constitues respectivement des 
35 donnees simples "cle" 11 et "contact" 17i pour le premier, des donnees 

simples "cle" 11 et "contact" 172 pour le second, et "cle" 11 et "contact" 
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17 1 pour le troisieme; cela pouira etre realise, par exemple, par les 
instructions SQL : 

INSERT INTO "EntreeAnnuaire_2" (cle, contact) VALUES (1234, "M. 
Laurent QUEREL") 

5 INSERT INTO "EntreeAnnuaire_2" (cle, contact) VALUES (1234, "M. 

Jean-Frangois QUENTIN") 
et: 

INSERT INTO "EntreeAimuaire_2" (cle, contact) VALUES (1234, "M. 
Gilles ANDRE") 

10 On constate que, dans la technique anterieure, on ejffectue done une 

operation d'ecriture pour stocker I'ensemble 31, deux operations d'ecriture pour 
stocker les ensembles 41, et trois Ventures pour stocker les ensembles 51, soit un 
total de six ecritures pour stocker I'ensemble des donnees correspondant k I'objet k 
stocker 6. 

15 - 2°/ Lecture d'un objet 6 dans la base de donnees 2 

La lecture d'un objet 6, ayant pour donn^e unique "cle" 11 une valeur 
donn^e telle que 1234, et comportant les doim^s simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associ6es aux donnees simples "rue" 15, "ville" 16 et 
"contact" 1 7 en nombre variable, se fera classiquement par les Stapes suivantes : 
20 - lecture, ^ I'aide de la fonction correspondante du SGBDR, de I'ensemble 

principal 31, constitue des donnas simples "cle" 11, "nom" 12, 
"telephone" 13 et "telecopie" 14, dont la donn^e "cle" 11 a la valeur 
donnee 1234 ; cela pourra etre realise, par exemple, a I'aide de 
I'instruction SQL ; 

25 SELECT * FROM "EntreeAnnuaire_main" WHERE cle= 1 234 

- lecture, I'aide de la fonction correspondante du SGBDR, de tous les 
ensembles 41 de la table 4 comportant la valeur 1234 dans leur donnee 
"cle" 11, c'est-a-dire, lecture des deux ensembles 41 1 et 4I2 constitues 
respectivement des donnees simples "cle" 1 1, "rue" 15i, "ville" I61 d'une 
30 part, et des donnees simples "cle" 11, "rue" 152, "ville" I62 d'autre part ; 

cela pourra 6tre obtenu, par exemple, a I'aide de I'instraction SQL : 
SELECT * FROM "EntreeAnnuaire_l" WHERE cle=1234 
cette instruction retrouvera alors les deux ensembles de donnees 41] et 
4I2 ; 

35 - lecture des ensembles 51 a I'aide de la fonction correspondante du 

SGBDR, en relisant tous les ensembles 51 de la table 5 comportant la 
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valeior doim6e 1234 dans leur donnee "cle" 11, c'est-a-dire, lecture des 
trois ensembles 51i, Sh et 5U constitues respectivement des donnees 
simples "cle" 11 et "contact" 17i povir le premier, des domi6es simples 
"cle" 1 1 et "contact" 172 pour le second, et "cle" 1 1 et "contact" 17i pour 
5 le troisidme; cela pourra iHre obtenu, par exemple, a I'aide de 

rinstruction SQL : 

SELECT * FROM "EntreeAnnuaire_2" WHERE cle=1234 

cette instruction retrouvera alors les trois ensembles de domi^es 5 1 1 , 5 1 2 

et5l3. 

1 Q De meme que pour I'opeiation d'6criture, on constate que, dans la technique 

anterieiare, on effectue done au total de six operations de lecture d'ensemble de 
domiees dans les tables 3, 4 et 5 pour relire I'ensemble des demises correspondant k 
I'objet 6 k relire. 

3°/ Suppression d'un objet 6 dans la base de donnees 2 

15 La suppression d'un objet, constitue des donnees simples "cle" 11, "nom" 

12, "telephone" 13 et "telecopie" 14, ayant pour donnee "cle" 11 une valeur donnee, 
par exemple 1234, et comportant les doimees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples en nombre variable 
"rue" 15, "ville" 16 et "contact" 17, se composera classiquement des 6tapes 

20 suivantes : 

- suppression de I'ensemble principal 31 ayant pour doimee "cle" 11 la 
valeur donnee 1234 a I'aide de la fonction coirespondante du SGBDR ; 
cela pourra etre realist, par exemple, d. I'aide de I'instruction SQL : 
DELETE FROM "EntreeAnnuaire_main" WHERE cle=1234 

25 - suppression des ensembles 41 ayant comme donnee "cle" II la valeiu: 

donnee 1234 h I'aide de la fonction correspondante du SGBDR, c'est-a- 
dire, suppression des deux ensembles 41 1 et 4I2 constitues 
respectivement des donnees simples "cle" 11, "rue" 15i, "ville" I61 d'une 
part, et des donnees simples "cle" 11, "rue" 152, "ville" I62 dautre part ; 

30 cela poxarra etre realise, par exemple, a I'aide de I'instruction SQL : 

DELETE FROM "Entree Annuaire_l " WHERE cle=l 234 

- suppression des ensembles 51 ayant comme donnee "cle" 11 la valeur 
donnee 1234 a I'aide de la fonction correspondante du SGBDR, c'est-i- 
dire, suppression des trois ensembles 51 1, Sh et 5I3 constitues 

35 respectivement des donnees simples "cle" 11 et "contact" 17i pour le 

premier, des donnees simples "cle" 11 et "contact" 172 pour le second, et 
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"cle" 11 et "contact" 173 pour ie troisifeme ; celapouira 6tre i^alis6, par 
exemple, a I'aide de rinstruction SQL : 
DELETE FROM "EntreeAnnuaire_2" WHERE cle=l 234 
De m&me que pour les operations d'^criture ou de lecture, on constate que, 
5 dans la technique anterieure, on effectue au total de six operations de suppression 
d'ensemble de donnfes dans les tables 3, 4, et 5 pour supprimer I'ensemble des 
donnees correspondant & I'objet 6 4 supprimer. 

4°/ Recherche d'un objet 6 dans la base de donnfes 2 

Toujours dans la technique ant^rieure, la recherche d'un objet ayant, par 
1 0 cxcmple, pour donn6e 12 "nom" la valeur "OTOOBE", et comportant \m ensemble 
?I de donnees simples en nombre fixe "nom" 12, "telephone" 13, "telecopie" 14 
a^Mx-iocs aux donnees simples "rue" 15, "ville" 16 et "contact" 17 pr^sentes dans les 
ensembles 41 et 51, sera constituee classiquement des Stapes suivantes : 

- recherche, a I'aide de la fonction correspondante du SGBDR, de 
15 I'ensemble principal 31, constitue des donnees simples "cle" 11, "nom" 

12. "telephone" 13 et "telecopie" 14, dont la donnee 12 "nom" possede la 
valeur "OTOOBE" doimee ; cela pourra 6tre realise, par exemple, a I'aide 
de I'instruction SQL : 

SELECT * FROM "EntreeAnnuaiie_niain" WHERE nom-"OTOOBE" 

20 - lecture, a I'aide de la fonction correspondante du SGBDR, de tous les 

ensembles 41 de la table 4 ayant, dans leur donnee "cle" 11, la valeur 
contenue dans la donnee "cle" 1 1 de I'ensemble 31 venant d'etre retrouve 
dans la table 3, c'est-a-dire, lecture des deux ensembles 41 1 et 4I2 
constitu6s respectivement des donn6es simples "cle" 11, "rue" 15i, "ville" 

25 I61 d'une part, et des donn&s simples "cle" 11, "rue" 152, "ville" I62 

d'autre part ; en supposant que la valeur contenue dans la donn6e "cle" 1 1 
de Tensembie 3 1 retrouve precedemment soit egale k 1234, cela pourra 
etre obtenu, par exemple, a I'aide de I'instruction SQL : 
SELECT * FROM "EntreeAnnuaire_l" WHERE cle= 1234 

30 - lecture, a I'aide de la fonction correspondante du SGBDR, de tous les 

ensembles 51 de la table 5 ayant dans leur donnee "cle" 11, la valeur 
contenue dans la donnee "cle" 11 de I'ensemble 31 venant d'etre retrouve 
dans la table 3, o'est-^-dire, lecture des trois ensembles 51i, 5I2 et 5I3 
constitues respectivement des dormees simples "cle" 11 et "contact" 17, 

35 pour le premier, des donh&s simples "cle" 11 et "contact" 172 pour le 

second, et "cle" 11 et "contact" 17i pour le troisieme ; en supposant 
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toujours que la valeur contenue dans la doimee 1 "cle" de I'ensemble 31 
retrouve soit egale a 1234, cela pourra Stre obtenu, par exemple, a I'aide 
de rinstruction SQL : 

SELECT * FROM "EntreeAimuaire_2" WHERE cle=1234 

5 De meme que pour les operations d'ecriture, de lecture ou de suppression, on 

constate que, dans la technique ant^rieure, on relit au total de six ensembles de 
donnees depuis les tables 3, 4 et 5 pour retrcuver I'ensemble des dormees 
correspondant k I'objet 6 recherche. 

En se referant maintenant k la figure 2, dans le proced6 de I'invention, la 

10 base de donnees 2 comporte une table principale 3 stockant les ensembles 31 de 
donnees simples en nombre fixe "cle" 11, "nom" 12, "telephone" 13 et "telecopie" 14, 
et cette table principale est en relation avec une unique table armexe 7 contenant les 
ensembles 71 de donnees simples en nombre variable, constituds des donnas 
simples "contact" 17. De fa5on classique, une donnee d'identification unique "cle" 

15 11, presente dans les ensembles 31 et 71 respectivement stockes dans les tables 3 et 
7, est utilisee pour mettre en relation, c'est-a-dire faire se referencer, la table 
principale 3 et la table annexe 7, et pour identifier de fafon unique un objet 6 dans la 
base de donnees 2. 

1 °/ Ecriture d'un objet 6 dans la base de donnees 2 

20 L'ecriture, ou creation, d'un objet identifie par une valeur unique telle que 

1234 et comportant les donnees simples en nombre fixe "nom" 12, "telephone" 13, 
"telecopie" 14, associ6es aux donnees simples "rue" 15, "yille" 16 et "contact" 17 en 
nombre variable, comportera, dans le procede de I'invention, les etapes suivantes : 

- ecriture de I'ensemble d'informations principal 31, constitu6 des donndes 
25 simples "cle" 11, "nom" 12, "telephone" 13 et "telecopie" 14, a I'aide de 

la primitive adequate du SGBDR, ce qui conduit a une operation 
d'ecriture pour cet ensemble 31 ; en supposant toujours que la valeur 
pour la donnee "cle" 11 soit 1234, cela pourra etre realise a I'aide d'une 
instruction SQL telle que : 
30 INSERT INTO "EntreeAnnuaire_main" (cle, nom, telephone, telecopie) 

VALUES (1234i "OTOOBE", "+33(0)1 44 34 85 03", "+33(0)1 44 34 85 

01") 

- stockage de la valeur 1234 dans les donnees "cle" 11 des trois ensembles 
de donnees simples 71i, 7I2, 7I3, stockage de la premiere donnee "rue" 

35 dans la donnee 15i de I'ensemble 71 1 de la table 7, stockage de la 

premiere donnee "ville" dans la doimee I61 de I'ensemble 71 1, stockage 
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de seconde donn6e "rue" dans la donn6e ISj de I'ensemble 71 2, stockage 
de la seconde donn^e "ville" dans la donnee I62 de I'ensemble 7I2, 
stockage de la premiere donnee "contact" dans la donnfe 17i de 
I'ensemble 71 1, stockage de la seconde donnee "contact" dans la donn^ 
172 de I'ensemble 7I2, et stockage de la troisidme donnte "contact" dans 
la donn6e I73 de I'ensemble 7I3 ; 

- initialisation de la donnde 20i k la valeur booI6enne VRAI puisque les 
donnees isimples "me" 15i et "ville" I61 correspondantes sont ptesentes 
dans I'ensemble 71 u initialisation de la donn6e 21 1 a la valeur VRAI 
puisque la donnee "contact" 17i correspondante est presente dans 
I'ensemble 71], initialisation de la donnee 2O2 a la valeur VRAI puisque 
les donnees simples "rue" 152 et "ville" I62 correspondantes sont 
presentes dans I'ensemble 71 2, et initialisation de la donnee 2I2 a la 
valexir VRAI puisque la donnee "contact" 172 correspondante est 
presente dans I'ensemble 71 2; par contre, initialisation de la donnee 2O3 k 
la valeur FAUX puisque les donnees simples "rue" I53 et "ville" I63 
correspondantes sont absentes de I'ensemble 7I3 ; enfin, initialisation de 
la donnfe 2I3 k la valeur VRAI puisque la donnee "contact" I73 
coitespondante est bien presente dans I'ensemble 7I3 ; 

- &riture les trois ensembles 71 1, 7I2, 7I3 dans la base de domi6es 2 k 
I'aide d'instructions SQL telles que : 

INSERT INTO "EntreeAnnuaire_annex" (cle, presence_adresse, 
presence_contact, rue, ville, contact) VALUES (1234, TRUE, 
TRUE, "3bis, rue du Docteur-Foucault", "92000 NANTERRE", 
"M. Laurent QUEREL") 

INSERT INTO "EntreeAnnuaire_annex" (cle, presence_adresse, 
presence_contact, rue, ville, contact) VALUES (1234, TRUE, 
TRUE, "34, bd Haussmann", "75009 PARIS", "M. Jean-Fran9ois 
QUENnN") 

et: 

INSERT INTO "EntreeAnnviaire annex" (cle, presence adresse, 

presence_contact, rue, ville, contact) VALUES (1234, FALSE, 
TRUE, "", "M. Gilles ANDRE") 
Ainsi, dans le precede selon I'invention, le nombre d'ecritures dans la base 
de donnees 2 est 6gal k quatre, au lieu de six dans la technique anterieure. 
2"/ Relecture d'un objet 6 dans la base de donnees 2 
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La lecture d'un objet 6, ayant pour donnee unique "cle" 11 line valeur 
doirnee telle que 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples "rue" 15, "ville" 16 et 
"contact" 17 en nombre variable, se fera, dans le precede de I'invention, par les Stapes 
5 suivantes : 

- lecture, k I'aide de la fonction correspondante du SGBDR, de I'ensemble 
principal 31, constitue des donnfes simples "cle" 11, "nom" 12, 
"telephone" 13 et "telecopie" 14, dont la donnee "cle" 11 a la valeur 
donn6e 1234, ce qui conduit a une operation de lecture pour cet 
1 0 ensemble ; cette operation de lecture pourra atre realisee, par exemple, a 

I'aide de I'instruction SQL : 

SELECT * FROM "EntreeAnnuaire_main" WHERE cle=1234 

a I'aide des donnees pr^sentes dans I'ensemble 31, le proced^ de 

I'invention restitue les donnees fixes de I'objet 6 ; plus pr6cis6ment, le 

15 pTOc6d6 initialise la donnee en nombre fixe "nom" de I'objet 6 a I'aide de 

la donnee 12 presente dans I'ensemble 31 relu, il initialise la donnee en 
nombre fixe "telephone" de I'objet 6 k I'aide de la donnee 13 de ce mSme 
ensemble, et il initialise la donnte en nombre fixe "telecopie" de I'objet 6 
a I'aide de la donnee 14 ; 

20 - lecture, dans la table 7, des ensembles 71 de cette table comportant la 

valeur 1234 dans levir donnee "cle" 11 ; cela pourra etre r6alis6 k I'aide 
d'tm instruction SQL telle que : 

SELECT * FROM "EntreeAnnuaire_annex" WHERE cle=1234 
les trois ensembles de donn6es 71 1, 7l2, 7I3 sont ainsi relus, moyennant 
25 trois operations de lecture d'ensemble de donnees dans la base de doraides 

2; 

ainsi que cela a ete decrit precedemment, ces trois ensembles 71 1, 7I2, 

7I3 de donnees sont chacun constitues de la donnee "cle" 1 1, des donnees 

simples en nombre variable "rue" 15, "ville" 16 et "contact" 17, et des 
30 donnees 20 et 21 indiquant respectivement la presence ou non de 

I'ensemble en nombre variable "rue", "ville" et de la donn6e en nombre 

variable "contact" dans I'ensemble 71 conceme ; 
- reconstitution des donnees variables de I'objet 6 a I'aide des donnees 

presentes dans les ensembles de donnees 71 1, 7I2, 7I3 pr6c6demment 
35 relus ; pour cela, le procede examine les donnees 20 et 21 dans chaque 

ensemble 71 1, 7I2, 7I3 relu ; 
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plus precisement, si le contenu de la donn6e booleenne 20 1 
contenue dans I'ensemble 71 1 est VRAI, cela signifie qu'il existait a 
I'origine un premier ensemble "rue", "ville" dans I'objet 6 stocke ; 
dans ce cas, le precede selon I'invention creera alois un premier 
sous-objet en nombre variable "adresse" dans I'objet 6 ; il lemplira 
les doim^es en nombre variable "rue" et "ville" de ce premier sous- 
objet avec respectivement les donn^es 15] et 16i contenues dans 
I'ensemble 71i ; de mdme, si le contenu de la donn6e booleenne 21 1 
est vrai, cela signifie qu'il existait k I'origine \me premiere donnee 
en nombre variable "contact" dans I'objet 6 ; dans ce cas, le proced6 
de I'invention cr6era tme premiere dorm^e en nombre variable 
"contact" dans I'objet 6 ; 

en utilisant la m^e demarche que ci-dessus, le procede de 
rinvention creera un second et un troisifeme sous-objet "adresse" en 
nombre variable "rue", "ville" si les contenus des donnees 
booleennes 2O2 et 2O3 contenues respectivement dans les ensembles 
7I2 et 7I3 sont VRAI, et il initialisera les donnees "rue" et "ville" 
de ces second et troisieme sous-objets en nombre variable "adresse" 
avec les donnees respectivement 152 et I62 d'une part, et ISs et I63 
d'autre part respectivement contenues dans I'ensemble 7I2 et 
I'ensemble 7I3 ; 

de meme, le procdd^ de I'invention cr6era une seconde et une 
troisieme donnee en nombre variable !' contact" si les contenus des 
donnees booleennes 2I2 et 2I3 contenues respectivement dans les 
ensembles 71 2 et 71 3 sont VRAI, et il initialisera ces seconde et 
troisiemes donnees en nombre variable "contact" avec les donnees 
172 et 173 respectivement contenues dans I'ensemble 7 12 et 
I'ensemble 7I3 ; 

en supposant que les donnees relues proviennent de I'exemple 
d'ecriture d'objet 6 precedemment decrit, les donnees simples 20i, 
2O2, 2I1, 2I2 et 2I3 seront a la valeur VRAI, tandis que la donnee 
2O3 sera a la valeur FAUX; dans ces conditions, le procede de 
I'invention reconstituera exactement deux ensembles de donnees 
"adresse", en nombre variable dans I'objet 6 relu, ainsi que trois 
donnees en nombre variable "contact" ; I'objet 6 d'origine sera done 
parfeitement reconstitue. 
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Poiar relire I'objet 6, le proc6de effectue done au totsd trois operations de 
lecture d'ensembles de donntes dans la base de donndes 2, contre six pour la 
technique ant^rieure. 

3°/ Suppression d'objet 6 dans la base de donnas 2 
5 La suppression dhin objet ayant pour donn6e "cle" 1 1 une valeur donn^e, par 

exemple 1234, et comportant les donn^es simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donn6es simples en nombre variable 
"rue" 15, "yille" 16 et "contact" 17, se composera, dans le proc6de de I'invention, des 
stapes suivantes : 

IQ _ suppression de I'ensemble principal 31, constitue des donnees simples 

"cle" 11, "nom" 12, "telephone" 13 et "telecopie" 14, ayant pour donnee 
"cle" 1 1 la valeur doimee 1234, a I'aide de la fonction coirespondante du 
SGBDR ; cela pourra etre realise, par exemple, a I'aide de Tinstruction 
SQL: 

15 DELETE FROM "EntreeAnnuaire_main" WHERE cle=l 234 

- suppression de I'ensemble annexe 71, ayant pour dbnn^e "cle" 11 la 
valeur donnee 1234, a I'aide de la fonction correspondante du SGBDR ; 
cela pourra 6tre realist, par exemple, k I'aide de Tinstruction SQL : 
DELETE FROM "EntreeAnnuaiie_annex" WHERE cle=1234 

20 A nouveau, le nombre d'operations de suppression d'ensembles de doim6es 

par le SGBDR s'eleve h un total de quatre dans le proc6d6 de I'invention, contre six 
dans la technique anterieure. 

4°/ Recherche d'xm objet 6 dans la base de donnees 2 

- recherche, a I'aide de la fonction correspondante du SGBDR, de 
25 I'ensemble principal 31, constitud des donnees simples "cle" 11, "nom" 

12, "telephone" 13 et "telecopie" 14, dont la donnee 12 "nom" possede la 
valeur "OTOOBE" donnee ; cela pourra 6tre r6alis6, par exemple, a I'aide 
de I'instruction SQL : 

SELECT * FROM "EntreeAnnuaire_main" WHERE nom="OTOOBE" 
30 - lecture, a I'aide de la fonction correspondante du SGBDR, de tons les 

ensembles 71 de la table 7 ayant, dans leur donnee "cle" 11, la valeur 
contenue dans la donnee "cle" 11 de I'ensemble 31 venant d'etre retrouve 
dans la table 3, c'est-a-dire, lecture des trois ensembles 71 1, 7l2 et 7I3 
ayant la structure de donnees precedemment decrite ; en supposant que la 
35 valeur contenue dans la donnee "cle" 11 de I'ensemble 31 retrouv^ 
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pr6c6deimnent soit 6gale h 1234, cela pourra 6tre obtenu, par exemple, a 
I'aide de rinstruction SQL : 

SELECT * FROM "EntreeAimuaire_axinex" WHERE cle=1234 
- reconstitution des donn^es ou des sous-objets en nombre variable de 
5 robjet 6 k retire k I'aide des donn^es contenues dans les trois sons- 

ensembles relecture ; cette reconstitution est identique a celle d6crite au 
paragraphe 2°/ ci-dessus ; en consequence, elle ne sera pas d6crite plus en 
detail. 

A nouveau, le nombre d'operations de recherche d'ensembles de donnees par 
10 le SGBDR s'eleve a un total de quatre dans le precede de I'invention, contre six dans 
la technique anterieure. 

Ainsi, dans les quatre operations de base effectuees par un SGBDR, 
rutilisation du proced6 de I'invention permet une reduction d'un tiers du nombre 
d'operations d'ensembles de donnees dans tous les cas. L'exemple presente ci-dessus, 
.15 volontairement simple pour des raisons de clarte de I'expose, ne rend pas 
necessairement bien compte des gains tr^s importants que pent apporter le precede 
dans un cas pratique comportant im nombre tables en relation beaucoup plus 
important. 

Dans un cadre plus general, on d^signe, dans ce qui suit, par Na le nombre 
20 de tables annexes Tj, par Np le nombre total d'ensembles principaux 3 1 dans la table 
principale 3, et par K,-, pour i variant de 1 k Na, le nombre total d'ensembles de 
donnees presents dans une table annexe Ti. 

Avec ces conventions, dans la technique anterieure, le nombre moyen 
d'operations pour effectuer une entree-sortie conceroant un objet 6 dans une table Ti 
25 donnee sera, en moyenne, egal a Kf/Na, et le total genera] pour une entree-sortie 
complete comprenant I'ensemble principal 31 et les Na ensembles de donn6es 
presents dans les Na tables annexes Tj sera done egal k : 

.Na„t=l + i; Ki/Np 

i=I 

30 Dans le cas du proced6 de la pr^sente invention, le nombre d'entr6es-sorties 

necessaire pour obtenir les ensembles de donnas contenus dans I'unique table 
annexe sera done 6gal en moyenne a Max (Ki)/Np, du fait que I'unique table annexe 
comporte un nombre d'ensembles 6gi au maximum des nombres d'ensembles 
presents dans les ensembles d'ensembles en relation ; par cons^uent, le total g6n6ral 
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pour une entree-sortie complete comprenant I'ensemble principal 31 et les ensembles 
de donnees contenus dans I'unique table annexe sera done 6gal : 

Np«»=l + lvSx(Ki)/Np 

5 On voit que sauf circonstance tres exceptionnelle, le nombre moyen 

d'entrees-sorties Nproc avec le proc6d6 de la pr6sente invention sera touj ours tr^s 
inf^rieur au nombie moyen d'entrees-sorties Nant sans ce precede. Dans le cas 
favorable, mais relativement frequent, oii le nombre d'ensembles de donnees est 
sensiblement le m€me dans les diverses tables annexes, le procede selon I'invention 
1 0 permet un gain en performances atteignant un facteur egal au rapport Nproc/Naatj c'est- 
a-dire : 

l+NSx(Ki)/Np 



1+ Y Ki/Np 



soit en utilisant I'hypothtee que les divers Ki sont sensiblement 6gaux entre eux, et, 
1 5 done au maximum d'entre eux : 

l + M5x(Ki)/Np 



l + NaxMax(Ki)/Np 



soit en negligeant 1 devant Max (KO/Np, un rapport de valeur 1/Na, ce constitue une 
diminution tres importante du nombre d'entrees-sorties des que le nombre de tables 
annexes augmente. 

20 Ce proced6 est done particvdierement souhaitable dans toutes les 

applications de bases de donnees relationnelles dans lesquelles les performances 
constituent un facteur critique, telles que les applications temps reel ou celles 
utilisant des serveurs de bases de donnees tres soilicites, comme ceux qui se 
rencontrent dans les reservations centralisees par un reseau, ou dans la consultation 

25 de bases de donnees via le reseau mondial Internet. 

En outre, I'utilisation du langage XML pour representer les objets stockes 
dans la base de donnees 2 permet I'utilisation de patrons d'objets XML pour filtoer 
certaines donnees des objets 6 entrants et sortants de la base de donnas 2. -Ainsi, 
dans le mode de rdaHsation pr6f6re de la presente invention, des patrons d'objets 
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XML 61 , coUectivement denommes I/O Format et conformes h une description XML 
Schema, sont utilises pour realiser tin tel filtrage. 

Plus precis^ment, ces patrons d'objets XML I/O Format 61 supprimeront 
certaines donnees sensibles des objets entrants, comme des donnees concemant la 
5 validity des donnees contenues dans un objet 6, de fa^on a ce que ces donnees 
sensibles ne puissent etre, en tout 6tat de cause, modifi6es depuis lereseau 60, et h ce 
que leur modification ne puisse Stre effectu^e que par un op6rateur intervenant 
directement sur rordinateur serveur 1 . 

De meme, les patrons d'objets XML I/O Format 61, en fonction des domi6es 

10 effectivement utilises par un utilisateur sur le r6seau 60, supprimeront dans les 
donnees d'un objet 6 transmises sur le reseau 60 les donn6es qui ne seraient pas 
utilisees par ledit utilisateur. Compte-tenu de ce que, dans la pratique, les donnees 
transmises pour un objet 6 ne reprdsentent habitueliement qu'une faible partie de 
I'ensemble des donnees de cet objet, ce precede peimet une reduction substantielle du 

15 volume des donnees transmises par I'ordinateur serveur 1, ce qui est particulierement 
interessant dans le cas d'ordinateur serveur 1 tres charg6, tels que ceux qui se 
rencontrent dans I'lntemet. 

En outre, ce proc6d6 permet de prendre en compte difKrents niveaux de 
security attaches aux utilisateurs se connectant via le reseau 60, en associant a chaque 

20 niveau de securite un patron eliminant des doimees transmises -a rutilisateur les 
donnees non autorisees pour le niveau de security de I'utilisateur. 

En outre, du fait que ce proc6d£ garantit que seules les donnees conformes 
au patron d'objet I/O Format 61 utilise seront transmises, il n^ aura pas lieu de 
demander la restitution par la base de donnees 2, des donnas 61iminees par le patron 

25 d'objet I/O Format 61 utilis6, et ainsi les donnees apparaissant dans les requStes SQL 
"SELECT" effectuees par le moteur COS Engine pourront etre limit^es aux seules 
• doimees transmises, ce qui diminuera de fa9on toute aussi sensible' la charge 
d'entrees-sorties dans la base de donnees 2 dans I'ordinateur servevir 1. 

Ce procede permet de focaliser la requete sur les tables de la base de 

30 donnees 2 et les donnees dans ces tables 3 et 7 qui sont effectivement utilisees dans 
la requete d'un utilisateur. Ainsi, dans le cas ou aucune donnee de la table annexe 7 
n'est utilisee dans la requete, le procede n'accedera pas a cette table 7 pour la requete, 
ce qui, a nouveau, permettra d'ameliorer sensiblement les performances de 
I'ordinateur serveur 1 mettant en oeuvre le procede de I'invention. 

35 Ainsi, I'utilisation du format XML et d'un patron d'objet au format XML 

permet d'imposer des regies de security sur les donn6es entrantes, de limiter 
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rutilisation de la base passante du reseau 60 aux seules doim6es necessaires et de 
diminuer en due proportion le volume des donnees 6chang6es avec la base de 
donnees 2. 

Dans le mode de realisation decarit ci-dessus, la donnee "cle" 11, identifiant 
5 de fa9on unique un objet 6, a 6t6 indiqu6e, pour des raisons de simplicity de I'expose, 
comma etant geree de fa9on explicite par le proced6 de I'invention. Toutefois, cette 
technique explicite n'est en aucime mani^re obligatoire, et elle peut parfaitement 6tre 
remplac6e par toute autre technique equivalente pouvant etre offeite par le SGBDR 
utilise. 

1 0 De meme, cette donnee "cle" 11 a 6te decrite comme etant constituee d'un 

scul nombre entier, mais elle peut tout aussi bien etre constitute de plusieurs parties. 
F'ar f xcmple, dans le mode de realisation prefer^ de I'invention, une donnee "cle" 11 
unique, appelee Object IDentifier ou OlD, est obtenue pour chaque objet 6 en 
concatcnanl une premiere partie constituee du nom logique du serveur 1 sur lequel 

15 reside la base de donnee 2, une seconde partie constitute du numero de la table 
priiicipale 3 dans la base de donnee 2, et une troisieme partie constitute du num6ro 
d'cnregistrcment de I'ensemble de donntes principal 3 1 dans ladite table 3. 

Le nom logique du serveur 1 etant unique sur le rtseau 60, la base de 
donnees 2 etant unique sur le serveur 1 oh elle est stockte, le numtro de la table 3 

20 etant unique dans la base de donnees et le numtro d'enregistrement de I'ensemble de 
donnees principal 3 1 etant unique dans la table 3, 1'OID 1 1 ainsi obtenu pour un objet 
6 sera done unique parmi I'ensemble des OID identifiant les objets 6 accessibles via 
le reseau 60. En outre, ce type de donnee "cle" 1 1 prtsentera I'inttret de permettre de 
localiser prtcisement le lieu de stockage d'un objet 6 quelconque sur la seule base de 

25 son OID 1 1 associe. 

Par ailleurs, dans I'exemple dtcrit ci-dessus, 11 a ett fait rtfeience a une 
application de type annuaire, mais le procede de I'invention est tgalement utilise dans 
des application de type conferences ou publications. 

D'une fa9on generate, la description ci-dessus ne doit pas etre comprise 

30 comme reduisant en quoi que ce soit la portee de la presente invention telle que 
revendiquee dans les revendications annextes. 
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REVENDICATIONS 

1. . Proced6 de stockage d'objets infoimationnels ou objets (6), dans une base de 

donn^es relationnelle (2) stockee dans un ordinateur serveiu: (1), ladite base 
de donnees relationnelle (2) etant constitute de tables, chaque table etant 
5 constituee d'un tableau d'ensembles de donntes simples, lesdits ensembles 

ayant la meme structure de donnees dans une meme table, chaque donnte 
simple d'une table etant designee par un identifiant unique dans ladite table, 
vm objet (6) etant constitue d'une ou plusieurs donnees simples pouvant fitre 
stockees dans ime table de ladite base de donnees (2), et/ou d'vm ou plusieurs 

10 objets emboites dans ledit objet, ledit emboitement pouvant fitre realise sur 

tm nombre quelconque de niveaux pour reaUser un objet (6), un objet 
emboite ou une donnee simple etant dit localement en nombre fixe s'U ou 
elle apparaJt exactement une fois dans I'objet le ou la contenant 
imm^diatement et 6tant dit localement en nombre variable dans le cas 

15 contraire, vine donnee simple apparaissant k un niveau quelconque dudit 

objet (6) etant dite globalement en nombre fixe si elle est localement en 
nombre fixe et si tous les objets la contenant sent localement en nombre 
fixe, une donnte simple apparaissant k un niveau quelconque dudit objet (6) 
6tant dite globalement en nombre variable si elle est localement en nombre 

20 variable ou si I'un quelconque des objets la contenant est localement en 

nombre variable, lesdites donnees globalement en nombre fixe d'un objet a 
stocker (6) etant stockees dans im ensemble de doimees principal (31) stocks 
dans ime table principale (3) de ladite base de donnees (2), lesdites donn6es 
simples globalement en nombre variable dudit objet k stocker (6) 6tant 

25 stockees dans une ou une ou plusieurs tables annexes (4, 5, 7) de ladite base 

de donnees (2), caracterise par le fait que, lorsqu'elles existent, les donnees 
simples globalement en nombre variable desdits objets (6) sont stockees 
dans une vmique table annexe (7) de ladite base de donnees, le procede 
errant un ou plusieurs ensembles de donnees annexes (71) pour stocker 

30 lesdites donnees simples globalement en nombre variable dans ladite unique 

table annexe (7). 

2. Proc6d6 selon la revendication 1, dans lequel chacim desdits un ou plusieurs 
ensembles annexes (71) eventuellement stock^s dans ladite unique table 
annexe (7) comporte en outre un ensemble (72) d'indicateurs booleens, 

35 chaque indicateur booleen etant associe a une donnte particuliere desdites 

doim6es simples globalement en nombre variable stockees dans ledit 
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ensemble annexe (71), ledit indicateur booleen indiquant si ladite donnte 
simple globalement en nombre variable associee est definie ou non dans 
ledit ensemble annexe (71). 

Precede selon la revendication 2, dans lequel certains desdits indicateurs 
booleens dudit ensemble (72) d'indicateurs bool6ens sont communs k 
plusieurs donn6es simples globalement en nombre variable lorsque lesdites 
donn6es simples sont localeinent en nombre fixe dans un mSme objet les 
contenant immediatement. 

Proc6de selon Tune quelconque des revendications pr6c6dentes, dans lequel 
ledit ensemble principal (31) associ6 au dit objet (6) a stockeir comporte une 
donnee (1 1) permettant d'identifier de fa9on unique ledit ensemble principal 
(31) dans ladite table principale (3). 

Proc6de selon la revendication 4, dans lequel ladite donnee vmique (11) est 
unique dans ledit ordinateur serveur (1). 

6. Proc6de selon I'une des revendications 4 ou 5, dans lequel ladite donnee 
unique (11) stockee dans ledit ensemble principal (31) associe au dit objet 
(6) a stocker est en outre stockee dans chacvm des ensembles amiexes (71) 
associes au dit objet (6) k stocker, pour permettre la mise en relation dudit 
ensemble principal (3) et du ou desdits ensembles aimexes (71) ^ventuels 
associes au dit objet (6) a stocker. 

7. Proc6d6 selon Tune quelconque des revendications 4 a 6, dans lequel ladite 
donnee unique (11) est constitute du nom logique de I'ordinateur serveur (1) 
sur ledit r6seau (60), du num6ro de table de ladite table principale (3) dans 
ladite base de donnees (2) et du numero d'ensemble de donnees dudit 
ensemble principal (31) dans ladite table principale (3), ledit nom logique de 
roidinateur serveur (1) etant unique sur ledit reseau <60), ladite base de 
donnees (2) ttant unique sur ledit ordinateur serveur (1), ledit numero de 
table de ladite table principale (3) etant unique dans ladite base de donn6es 
(2) et ledit num6ro d'ensemble de donnees dudit ensemble principal (31) 
etant unique dans ladite table principale (3). 

8. Procede selon I'une quelconque des revendications precedentes, dans lequel 
deux objets (6) a stocker sont dits de meme type s'ils sont constitues de 
donnees simples et d'objet emboites de meme type, deux objets (6) de mdme 
type ayant en commun vin irieme identifiant et les donnees simples et/ou les 
objets emboites se correspondant a un niveau quelconque desdits objets (6) 
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de meme type ayant en conunun un m€me identifiant, unique dans I'objet les 
contenant immediatement. 

9. Proc^d6 selon la revendication 8, dans lequel le pToc6d6 ci^e un identifiant 
global pour tous les objets (6) de mSme lype et pour toutes les donnees 

5 simples se correspondant a un niveau quelconque desdits objets (6) de 

meme type, ledit identifiant global etant ledit identifiant conimun pour 
lesdits objets de meme type, et ledit identifiant global etant obtenu, pour 
chacune desdites donnees simples se correspondant, par la concatenation des 
identifiants, dans les objets les contenant immediatement, de tous les objets 
1 0 contenant ladite donnee simple, et de I'identifiant de ladite doimee simple 

dans I'objet la contenant immediatement. 

10. Procede selon la revendication 9, dans lequel le nombre de caracteres de 
I'identifiant global est tronque au nombre de caracteres permis par ladite 
bu.'ie de donnees (2) povur I'identifiant d'lme donnee stockee dans ;me table de 

15 ladite base de donnas (2). . 

11. Proccdc selon la revendication 10, dans lequel une ambiguity pouvant 
apparaitre du fait de ladite troncature est resolue en effectuant les etapes 
consistant a : 

remplacer le dernier caractere alphabetique de I'identifiant global par le 
20 chif!fre z^o, ainsi que les eventuels chifi&es le suivant ; 

- augmenter d'lme unite le nombre constitu6 par I'ensemble des chiffres 

apparaissant a la fin dudit identifiant global jusqu'a ce que I'ambiguite 

disparaisse ou que les chiffres a la fin dudit identifiant global soient 

entierement constitues de chiffres neuf ; 
25 - repeter les etapes precedentes depuis le debut lorsque les chif&es 

apparaissant a la fin dudit identifiant global sont entierement constitues 

de chiffies neuf a Tissue de I'etape precedente. 

12. Procede selon I'un quelconques des revendications precedentes, dans lequel 
les objets (6) stockes dans la base de donnees (2) sont re9us ou transmis par 

30 I'ordinateur serveiir (1) via un reseau informatique (60) de type Internet 

13. Procede selon I'une des quelconques des revendications precedentes, dans 
lequel les donnees simples constituant lesdits objets (6) stock6s dans ladite 
base de donnees (2) sont de type texte. 

14. Procede selon la revendication 13, dans lequel lesdites donntes simples de 
3 5 type texte sont des donn6es ecrites en langage XML. 
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15. Precede selon la revendication 14, dans lequel lesdites donnees 6crites en 
langage XML sont conformes a une description (92) de type XML Schema. 

16. Procede selon la revendication 15, dans lequel un ensemble de donnees (95) 
au format XML est obtenu par une traduction automatique de ladite 

5 description (92), ledit ensemble de donn6es (95) et un ensemble de dorm^es 

complementaire (96) etant h leur tour traduits automatiquement en langage 
SQL pour definir et gerer la structure de la base de donnees (2), et pour 
contrdler les echanges de donnees avec ladite base de donnees (2). 

17. Procede selon Time quelconque des revendications 14 ^ 16, dans lequel une 
1 0 partie des donnees simples des objets (6) refus par ledit reseau (60) de type 

Internet est supprimee a I'aide d'vin patron, ou modele, d'objet (61) dcrit en 
langage XML, pour interdire la modification desdites donnees simples via 
ledit reseau (60). 

18. Procede selon Tune quelconque des revendications 14 a 17, dans lequel une 
1 5 partie des donnees simples des objets transmis via ledit reseau est supprimee 

a I'aide d'un patron d'objet (61) ecrit en langage XML pour limiter la 
transmission sur ledit reseau (60) a certaines dormees simples desdits objets 
(6). 

19. Procede selon la revendication 18, dans lequel la suppression de d'une partie 
20 des donnees simples contenues dans les objets (6) permet en outre 

d'optimiser les requStes k ladite base de donnees (2). 

20. Systeme de stockage d'objets informationnels ou objets (6), dans une base 
de donnees relationnelle (2) stodcee par vp ordinateur serveur (1), 
caracterise par le fait qu'il met en oeuvre le preclude selon I'une quelconques 

25 des revendications pr6cedentes. 
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